专利摘要:
The invention relates to a process for securing transactional data processing, a method implemented within a communication terminal (TC) comprising a processing module (ModT) of transactional data. Such a method comprises: a step of detection (100), by the processing module (ModT), of a display of at least one input area (ZoS) relative to a payment means datum; an activation step (110), by the processing module (ModT), of a contactless data reading module (ModSC); a step of obtaining (120), by the contactless data reading module (ModSC), at least one piece of payment means data coming from a means of payment; a step of providing (130) at least one input area (ZoS) with at least one payment means data item previously obtained.
公开号:FR3042894A1
申请号:FR1560270
申请日:2015-10-27
公开日:2017-04-28
发明作者:Hiba Koudoussi;Remi Geraud
申请人:Ingenico Group SA;
IPC主号:
专利说明:

Method of securing transactional data processing, terminal and corresponding computer program. Field The invention relates to the field of transaction processing. More particularly, the proposed technique relates to the field of transactional payment data processing, which transactional payment data must be secured. Thus, an object of the present technique is to provide a secure exchange of data when a transaction is performed. More specifically, an object of the present technique is to increase the security level of a data transmission in the context of a payment made with a smart mobile terminal (for example a smartphone or a tablet) and a payment card. payment. 2. Prior art The use of smart mobile terminals (such as smart phones - smartphones - or tablets) continues to grow. This progression is also illustrated when it comes to making a payment, for example on a website of a merchant. Thus, the number of transactions carried out on a smart mobile terminal is increasing day by day. It appears that this number could progress even more importantly. More specifically, there are traditionally two types of ways to make a payment on these types of terminals.
The first type is to make a payment directly in an application dedicated to a given merchant. For example, the merchant has an ecommerce application, which is installed on the user's terminal. It can make a purchase by selecting one or more goods or services and by paying by credit card (by entering or selecting data pre-entered in the fields of payment provided for this purpose).
The second type is to go, using a browser (software that allows you to browse a website) on a merchant's website. The website includes for example an interface dedicated to mobile terminals, to facilitate navigation on small screens. When he has finished selecting his goods or service, the user makes the payment. This often involves entering the credit card data (name, number, expiry date and verification code (cvv)) into the payment interface. However, such a seizure, within an interface not specifically dedicated to this can be problematic. Indeed, the combined effect of the small size of the displayed characters and the masking, by the virtual keyboard (keyboard displayed on the terminal screen), about half of the surface displayed on the screen, makes the input complicated bank card data for the user. This translates into a reduced conversion rate (conversion rate of the order into a real purchase).
To facilitate the act of purchase, two solutions are used: the first solution is to record, within a remote server, bank card data during a first purchase (this is called "enrolment" phase). in English). In this first solution, the operations carried out consist in particular of associating the user's bank card data with the existing user account. Thus, during its next purchase, the user will be able to directly select these data already entered to be able to pay for purchases. This solution is interesting, but it has the enormous disadvantage of having to record this data for each merchant: each merchant using his own database and his own architecture for managing receivables. Thus the user must still enter his credit card data as soon as he wants to pay for a purchase online, on a website or in an application he has not used previously.
The second solution is to use the properties of some browsers: they themselves memorize the entries made by the user. Since many websites use entry fields with identical names, the browser's auto store function can be used to enter information into these fields more quickly. This solution can be implemented easily but it presents several problems: this solution is limited to websites; websites do not all use the same name for a given input field; web sites, for payment normally use an encrypted connection (https) which does not allow entry of this type.
Thus, there is a need for a simple, inexpensive and quick solution for entering banking data relating to a payment to be made. Moreover, there is a need for a solution that is also secure. Indeed, one of the problems encountered is also in the authentication of both the user and the means of payment. It is therefore necessary to have, in a complementary manner, a solution that is effective in terms of security. 3. Summary
The present technique solves at least some of the problems of the prior art. More particularly, the proposed technique relates to a method for securing data processing from a contactless payment means. Such a method notably comprises the automatic acquisition of data coming from the payment means on the one hand and, on the other hand, securing the transmission and processing of these data within a communication network, so that they are treated.
The technique thus relates to a process for securing transactional data processing, a method implemented within a communication terminal comprising a transactional data processing module. Such a method comprises: a step of detection, by the processing module, of a display of an input area relating to a payment means data; an activation step, by the processing module, of a contactless data reading module; a step of obtaining, by the contactless data reading module, at least one means of payment data from a payment means; a step of providing, at the input area, at least one payment means data previously obtained.
Thus, the proposed technique makes it possible to greatly simplify the data entry required for the transaction. In fact, the user merely presents his (non-contact) means of payment to the communication terminal so that it is read and the processing module automatically evaluates the data necessary for processing.
Depending on the embodiments and needs, the data obtained by the transactional module of the communication terminal are for example the surname, the first name, the credit card number, the expiry date, the visual verification code.
According to a particular characteristic, the method of securing processing comprises a step of generating, by the processing module, a current authentication code as a function of an identification of the communication terminal.
According to a particular characteristic, the step of generating the current authentication code comprises: a step of obtaining an identification data of the communication terminal; a step of obtaining an authentication data of said user to which said communication terminal is associated; a step of encrypting said identification data of the communication terminal and said authentication data of said user, delivering the current authentication code.
According to a particular characteristic, the method of securing treatment comprises a step of providing, in a previously selected input area, said current authentication code.
Thus, in addition to the usual data, usually entered by the user in the input fields provided for this purpose (name, last name, card number validity date zone), the method makes it possible to secure the transaction by entering a data calculated within the terminal itself. This data makes it possible to ensure that the transaction is carried out within an identified terminal.
According to a particular characteristic, the current authentication code is provided in an entry area of the credit card verification code.
Thus, the proposed technique does not require the implementation of a new input area. Indeed, by using the input area of the verification code (also called "card verification code" or "card verification value"), it is not useful to develop or redevelop new applications, including new ones. payment applications (eg on websites and / or merchant applications). At the end of the implementation of this technique, according to this last characteristic, the fields required for payment have been entered automatically. In addition, the verification code field includes the previously generated authentication code. The user is therefore able to validate the payment.
According to a particular characteristic, this method also comprises a preliminary step of obtaining an implementation value of the process of securing treatment and when it is the first occurrence of implementation of the method. the method comprises a step of creating a data representative of a link between the communication terminal and a transaction processing server.
Thus, during the first implementation of the service, it is possible to establish a strong link between the communication terminal and one or more servers in charge of the implementation of the transaction. This is for example a server of a payment service provider.
According to a particular feature, the step of creating a reference authentication data between the communication terminal and a transaction processing server comprises: a step of obtaining an identification data of the communication terminal; a step of obtaining an authentication data of said user to which said communication terminal is associated; a step of encrypting said identification data of the communication terminal and said authentication data of said user, delivering the data representing the link between the payment terminal and the server of the payment service provider; a step of transmitting said reference authentication data to a server of the payment service provider.
In another aspect, the present technique also relates to a process for securing processing of transactional data, within a server.
According to one particular characteristic, the method comprises, when receiving data from said at least one input area by a processing server, at least one step of comparing at least one piece of data transmitted within said input area and the reference authentication data, delivering a validation assertion of the transaction.
According to another aspect, the invention also relates to an intelligent communication terminal characterized in that it comprises a transactional data processing module and a contactless data acquisition module, characterized in that the processing module comprises: detection means, a display of at least one input area relating to payment means data; activation means, the non-contact data reading module; means for obtaining, by the contactless data reading module, at least one piece of payment means data from a payment means; means for supplying, to said at least one input area, at least one previously obtained payment means data.
According to a preferred implementation, the various steps of the methods according to the proposed technique are implemented by one or more software or computer programs, comprising software instructions intended to be executed by a data processor of a relay module according to the technique. proposed and being designed to control the execution of the different process steps.
Accordingly, the proposed technique is also directed to a program that can be executed by a computer or a data processor, which program includes instructions for controlling the execution of the steps of the methods as mentioned above, when are executed by a terminal and / or an integrated circuit.
This program can use any programming language, and be in the form of source code, object code, or intermediate code between source code and object code, such as in a partially compiled form, or in any other form desirable shape.
The proposed technique is also aimed at a data carrier readable by a data processor, and including instructions of a program as mentioned above.
The information carrier may be any entity or device capable of storing the program. For example, the medium may comprise storage means, such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or a magnetic recording medium, for example a floppy disk or a disk. hard, a flash memory or a memory of a storage of another type. On the other hand, the information medium may be a transmissible medium such as an electrical or optical signal, which may be conveyed via an electrical or optical cable, by radio or by other means. The program according to the proposed technique can be downloaded in particular on an Internet type network.
Alternatively, the information carrier may be an integrated circuit in which the program is incorporated, the circuit being adapted to execute or to be used in the execution of the method in question.
According to one embodiment, the proposed technique is implemented by means of software and / or hardware components. In this context, the term "module" may correspond in this document as well to a software component, a hardware component or a set of hardware and software components.
A software component corresponds to one or more computer programs, one or more subroutines of a program, or more generally to any element of a program or software capable of implementing a function or a program. set of functions, as described below for the module concerned. Such a software component is executed by a data processor of a physical entity (terminal, server, gateway, router, etc.) and is capable of accessing the hardware resources of this physical entity (memories, recording media, bus communication cards, input / output electronic cards, user interfaces, etc.).
In the same way, a hardware component corresponds to any element of a hardware set (or hardware) able to implement a function or a set of functions, as described below for the module concerned. It may be a hardware component that is programmable or has an integrated processor for executing software, for example an integrated circuit, a smart card, a memory card, an electronic card for executing a firmware ( firmware), etc.
Each component of the previously described system naturally implements its own software modules.
The various embodiments mentioned above are combinable with each other for the implementation of the proposed technique. 4. Figures Other features and advantages of the proposed technique will appear more clearly on reading the following description of a preferred embodiment, given as a simple illustrative and non-limiting example, and the appended drawings, among which: Figure 1 shows a synoptic of the general method implemented for the easy entry of payment data within a form; FIG. 2 shows the general steps implemented during the creation, by the communication terminal, of a current authentication code; FIG. 3 shows the steps implemented during the creation, by the communication terminal, of a current authentication code according to a particular embodiment; Figure 4 shows the steps implemented by a payment provider server to validate a current authentication code according to a particular embodiment; Figure 5 briefly describes the hardware architecture of a terminal adapted to implement the present technique; Figure 6 briefly describes the hardware architecture of a server adapted to implement the present technique. 5. Description 5.1. Recall of the principle
The general principle of the present technique rests on the one hand on the implementation of an intelligent communication terminal, comprising means for obtaining data from a means of payment. More specifically, a means for obtaining data from a payment means is in the form of a contactless communication module, such a module being more specifically a near-field communication module (NFC). This module receives from a processor of the communication terminal, a command or instruction to obtain data without contact. This may be a general order. In addition, this module is connected to a contactless antenna. This contactless antenna is used to send a signal to the means of payment and to receive a signal from this payment means.
The general principle of the present technique rests firstly on the implementation of an application installed within the intelligent communication terminal, an application comprising means for detecting and filling data input fields of payment means. .
A contactless payment means is for example in the form of a payment card (or credit card or debit card), comprising an antenna type NFC ("Near Field Communication"), this antenna comprising means of transmission of data to a receiver, when it receives, from this receiver, a request to that effect (the request taking for example the form of an electromagnetic signal). The antenna, called contactless antenna, can be connected to a processor. This processor may for example be the chip of the chip card or an additional processor embedded in the substrate of the card (as the antenna elsewhere). Incidentally, a contactless payment means may also be in the form of a communication terminal (a second communication terminal), which is provided with contactless data transmission means and possibly an application specifically intended to transmit data equivalent or identical to payment card data. Such an application may for example be a banking application, installed within the communication terminal, and which stores this data in a secure manner. In this case, for example, the technique is implemented by affixing this second communication terminal on the first communication terminal. Such an implementation is quite conceivable insofar as many people have both a tablet and a smartphone, the smartphone having the banking application while the tablet is used more general and freer by many people in the home, this tablet is not intended to contain confidential data.
With reference to FIGS. 1 and 2, the different stages of implementation of the method according to the present technique are presented from a general point of view. The implementation of the method comprises, beforehand, the selection within an application or a browser of one or more goods or services that the user wishes to acquire. When the user has selected what he wants to buy, he goes into the payment phase. This payment phase begins with the display of a screen (HTML page or page of an application) including data entry fields of payment means (for example bank card data). Therefore, the method of the present technique can be implemented. This general method comprises on the one hand a method implemented on the side of the communication terminal and on the other hand a method implemented on the side of a server (server of the payment service provider for example or bank server directly) . For the purposes of the present, both methods are presented in a nested manner to expose a clearest possible method of treatment. It is clear however that these methods can be implemented independently. The general method of treatment is presented in relation to FIG.
When displaying the screen comprising the data entry fields necessary for payment, a processing module (ModT) installed within the communication terminal (TC) (for example in the form of a particular application): detects (100) the display of these input areas; to do this, the processing module (ModT) implements a particular technique which is not the subject of the present; the active processing module (ModT) (110) then the non-contact data reading module (ModSC); in a complementary manner, the processing module (ModT) takes possession of the display made on the communication terminal; this taking of possession is carried out in the form of an interruption of the requesting application (specific application of the merchant or browser); the requesting application is "frozen" and the processing module (ModT) displays, in transparency, highlighted, for example the contactless payment logo is displayed by the processing module (ModT); the user uses his method of payment: the user affixes his payment method on the communication terminal; the contactless data reading module (ModSC) obtains (120) then, via a request and a response from the means of payment, the data necessary for payment. The number and designation of this data varies according to regulatory requirements and the practices of merchants and payment service providers; typically, the data obtained are: the surname, the first name, the expiry date and the credit card number and the verification code; the non-contact data reading module transfers the data obtained to the processing module (ModT) of the communication terminal; the processing module (ModT) then performs a filling (130) of the input areas according to the data received from the payment means: the processing module (ModT) assigns the received data to the previously identified areas; the processing module (ModT), at the same time, renders the control to the requesting application and cancels the display of the contactless payment logo (if it is displayed);
In a first embodiment of the present technique, the operations performed previously are sufficient. The user only has to check and validate the data entered. The rest of the payment process is the same as the existing one and the transaction continues as usual.
In a complementary manner, in other more secure embodiments, it is ensured that the terminal and the user carrying out the payment transaction are authorized to do so. Such an embodiment is particularly presented in relation with FIGS. 1 and 2. To do this, in these complementary embodiments, the processing module (ModT) of the communication terminal implements a creation step (125). a current authentication code (CAC). The creation of this current authentication code (CAC) comprises the following steps: a step of obtaining (125-1) an identification data of the communication terminal (IdTerm); such identification data, according to the embodiments may for example be a serial number, an IMSI (English for "International Mobile Subscriber Identity"), an IMEI (English for "International Mobile Equipment Identity") ") or other or a combination of these codes; a step of obtaining (125-2) an authentication data of said user (AuthU) to which said communication terminal is associated; such authentication data may be depending on the embodiment, a biometric data item (for example a signature of a fingerprint or a voice print) or a personal authentication code (PIN code type); an encryption step (125-6) of said identification data of the communication terminal and said authentication data of said user, delivering the current authentication code (CAC); this step of encryption, which is detailed later, is to encrypt and / or hashed the previously obtained data and produce an authentication code; of course, in a complementary manner, the data are encrypted or hashed with one or more encryption keys available to the processing module (ModT) s of the communication terminal of the user.
Once the processing module (ModT) has the current authentication code (CAC), it provides this current authentication code (CAC) to the applicant application. This provision can be made in several ways (for example by filling an "authentication code" field of the entry screen. According to an advantageous embodiment, however, the authentication code takes the place of the verification code. "CW" Thus, instead of the CW, which can be obtained in contactless reading from the means of payment (as previously indicated), this entry field CW is filled with the current authentication code (CAC) Advantageously, the method for calculating the current authentication code comprises at least one formatting step so that the size of the current authentication code corresponds to a size accepted by the input area relating to the CW. There is no difficulty in inserting the CAC in the area planned for the CW, so from the point of view of the payment service provider, the process of validating the transaction is somewhat different from the one used in the usual way. In fact, the validation by the user of the payment data entry form causes the transmission (direct or indirect: ie via the merchant's server) of these payment data to the data processing server. payment service provider. Therefore the payment service provider server (PSP server) implements the following steps: receipt of payment data (including including data automatically entered and the current authentication code (CAC)); checking the validity of the current authentication code (CAC); and when the current authentication code (CAC) is valid, validation of the transaction; when the current authentication code (CAC) is invalid, rejection of the transaction;
Depending on the embodiments, the validity check of the current authentication code (CAC) is implemented in several different ways: either the current authentication code (CAC) is directly compared to an authentication code of reference, previously received from the user and the communication terminal (for example during the first implementation of the service, as is explained later); in this case a simple comparison is made; either the current authentication code (CAC) data is used to decide the validity of the transaction, with respect to previously received data - this aspect is also described later.
When the data of the current authentication code (CAC) is used to perform a transaction validation, the following steps are implemented: decryption of the current authentication code (CAC); this decryption is implemented using a shared secret between the payment service provider's server and the user's communication terminal; this secret was shared during a registration phase with the payment service provider; an embodiment of this phase of registration and data sharing is described later; verification of the decrypted data: these data are for example the identification data of the communication terminal and the authentication data of the user.
Thus, the implementation of the described technique on the one hand facilitates online payment transactions for users and on the other hand to provide additional security for these online payment transactions.
An embodiment of the security operations is described below. It is clear, however, that this embodiment is only illustrative of the security operations that can be performed. More specifically, it is clear that other embodiments, based for example on the possession of private / public key pairs by the various parties (communication terminal, payment provider server) can also be implemented without going out. of the framework posed by this. 5.2. Description of an embodiment
In this embodiment, the manner in which the processing server is in possession of the hardware necessary for the subsequent verification of the current authentication code (CAC) (this step is called the registration step) is presented.
In this embodiment, the manner in which the current authentication code (CAC) is produced by the processing module (ModT) of the communication terminal is also presented. In this embodiment, the manner in which the processing server performs the verification of a current authentication code (CAC) is also presented.
To do this, we consider the data of a symmetric bilinear coupling e: G xG - * H with a group H of small size. We recall that such a function satisfies, for all integers x, y and all points g, h of G: e (gx, hy) = e (g, hy) x = e (gx, h) y = e (g , h) xy e (g, h) = e (h, g)
This bilinear coupling is used both for the registration step and for the subsequent verification steps. Typically, the group size is 128 bits. Such a group is considered to be small in relation to the usual size of these groups (typically 256 bits or even 512 bits). This means that in this application, the group includes numbers up to 128 bits long. This group includes for example 2128 elements: these elements are not (necessarily) numbers. In the considered application, for example, they are points of an elliptic curve. But it could be any object adapted to the present technique.
In this embodiment, it is possible to use a Tate coupling that is defined on any elliptic curve. However, for safety and performance reasons, it is possible to use Barreto-Naehrig curves. Such a bilinear coupling can for example be calculated using the Miller algorithm. These elements are given for information only. Indeed, any coupling could be suitable. However, this particular coupling has the double advantage of efficiency (it is one of the fastest) and generality (it applies in a large majority of cases). 5.2.1. Registration with the processing server
We call T (T = idTerm, for ease of notation) the identification data provided by the phone during registration, and B (B = AuthU, for ease of notation) the provided authentication data by the user. During registration, the processing server transmits an element g of the group H and the communication terminal transmits, in response, the data consisting of {gT, gB}.
In other words, the registration step comprises for the communication terminal, in this embodiment: a step of receiving, from the processing server, an element g; typically, such an element is an integer of the group H; a calculation step, by the processing module (ModT) of the communication terminal, of the data consisting of {gT, gB}; a step of transmission, by the communication terminal, of the previously calculated data.
This data is stored within the processing server. It is associated with the user's communication terminal. 5.2.2. Creation of the current authentication code (CAC) by the communication terminal
The creation of the current authentication code (CAC) is described in relation to FIG. 3. As before, the processing module obtains (125-1, 125-2) the identification data of the terminal (T) and the data user authentication (B). During the implementation of the payment, the processing module draws (125-3) a random number r; the processing module performs (125-4) also a marking of the time w, corresponding to the processing time of the transaction; the processing module also calculates (125-5) the transaction information v (for example, the amount, and / or the location of the transaction and / or the participants in the transaction). The processing module performs a calculation of the current authentication code (CAC): CAC = {wrT, vrB}.
The current authentication code (CAC), as well as the name, the card number and the expiry date, are transmitted to the processing server. The name, card number and expiry date can be encrypted with CAC during this transmission. 5.2.3. Checking the current authentication code (CAC) by the processing server
The verification of the current authentication code (CAC) is described in connection with FIG. 4. The processing server thus receives CAC = {a, b} as a verification code. The processing server also receives the other data of the transaction. The processing server being in possession of the identification data provided by the telephone during the registration, and B the authentication data provided by the user, it performs the following calculations:
It divides (200) a by the hour, and verifies that it has not received the same value of a / w during a predetermined time period (ie the last hour, or the last 10 minutes, for example ). If this happens, the transaction is canceled (210). if not, it checks (220) that: e (a / w, gB) = e (b / v, gT)
If this equality is true, then the transaction is validated (230) (and, if so, the name and PAN can be deciphered using the ACC).
Of course this embodiment of the technique is described for illustrative purposes. It is particularly described in the context of an implementation for an online payment. It is understood that this technique can also be applied to other types of payment and in particular to payments implemented in a direct payment to a merchant. In which case, the principle described above remains the same: instead of automatically entering a credit card data on a screen, a direct transmission of these read data to a merchant server is carried out so that these data are transmitted. and treated as if it were a payment made physically with a bank card on a physical payment terminal of the merchant. 5.3. Other features and benefits
In connection with FIG. 5, a communication terminal comprising means for executing the previously described method is described.
For example, the communication terminal comprises a memory 51 consisting of a buffer memory, a processing unit 52, equipped for example with a microprocessor, and driven by the computer program 53, implementing the steps necessary for the obtaining, filling, encrypting and transmitting transaction processing data. At initialization, the code instructions of the computer program 53 are, for example, loaded into a memory before being executed by the processor of the processing unit 52. The processing unit 52 receives, for example, an input screen or form to fill. The microprocessor of the processing unit 52 implements the steps of the method, according to the instructions of the computer program 53 to enable the data to be entered from a contactless payment means.
For this, the processing device comprises, in addition to the buffer memory 51, means for identifying the payment data entry areas, means for obtaining data from contactless payment means (such as a reader module). N FC), means for obtaining encryption material, encryption means. The processing device also comprises: detection means, a display of at least one input area relating to payment means data; such means are for example in the form of a particular detection module; means for activating, by the processing module, a contactless data reading module; such means are for example in the form of a connection circuit of said module; means for obtaining, by the contactless data reading module, at least one piece of payment means data from a payment means; these means are in the form of a credit card interrogation module for example; means for supplying said at least one input area with at least one previously obtained payment means data; these means are for example in the form of an automaton input.
These means can be controlled by the processor of the processing unit 52 according to the computer program 53.
In connection with FIG. 6, a processing server is described comprising means enabling the previously described method to be executed.
For example, the processing server comprises a memory 61 constituted by a buffer memory, a processing unit 62, equipped for example with a microprocessor, and driven by the computer program 63, necessary for the implementation of the functions verification of transaction data. At initialization, the code instructions of the computer program 63 are for example loaded into a memory before being executed by the processor of the processing unit 62. The processing unit 62 receives as input for example a an encrypted data set, comprising for example a current authentication code (CAC). The microprocessor of the processing unit 62 implements the steps of the processing method, according to the instructions of the computer program 63 to allow the decryption of the encrypted data and the verification of the current authentication code (CAC).
For this purpose, the device comprises, in addition to the buffer memory 61, means for obtaining an encryption / decryption key; these means can be in the form of a processor or a set of secure resources to secure the entry of authorization. The device also comprises cryptographic processing means; these processing means comprise for example a dedicated encryption processor.
These means can be controlled by the processor of the processing unit 62 as a function of the computer program 63.
权利要求:
Claims (10)
[1" id="c-fr-0001]
claims
1. A process for securing processing of transactional data, a method implemented within a communication terminal (TC) comprising a processing module (ModT) of transactional data, characterized in that such a method comprises: a step detecting (100), by the processing module (ModT), a display of at least one input area (ZoS) relating to a payment means data; an activation step (110), by the processing module (ModT), of a contactless data reading module (ModSC); a step of obtaining (120), by the contactless data reading module (ModSC), at least one piece of payment means data from a payment means; a step of providing (130) said at least one input area (ZoS) with at least one payment means data previously obtained.
[2" id="c-fr-0002]
2. Process for securing processing according to claim 1, characterized in that it comprises a step of generating (125), by the processing module (ModT), a current authentication code (CAC) as a function of an identification of the communication terminal.
[3" id="c-fr-0003]
3. method for securing processing according to claim 2, characterized in that the generation step (125) of the current authentication code (CAC) comprises: a step of obtaining (125-1) a datum d identification (IdTerm) of the communication terminal; a step of obtaining (125-2) an authentication datum (AuthU) of said user to which said communication terminal is associated; an encryption step (125-6) of said identification data of the communication terminal and said authentication data of said user, delivering the current authentication code (CAC).
[4" id="c-fr-0004]
4. process for securing processing according to claim 2 characterized in that it comprises a step of providing, in a previously selected input area (ZoS), said current authentication code (CAC).
[5" id="c-fr-0005]
Method for securing processing according to claim 4, characterized in that the current authentication code (CAC) is provided in an entry area (ZoS) of the bank card verification code.
[6" id="c-fr-0006]
6. Process for securing processing according to claim 1, characterized in that it further comprises a preliminary step of obtaining an implementation value of implementation of the process of securing treatment and when it is the first occurrence of implementation of the method, the method comprises a step of creating a data representative of a link between the communication terminal and a transaction processing server, said reference authentication data.
[7" id="c-fr-0007]
7. Process for securing processing according to claim 6, characterized in that the step of creating the reference authentication data between the communication terminal and a transaction processing server comprises: a step of obtaining a identification data of the communication terminal; a step of obtaining an authentication data of said user to which said communication terminal is associated; a step of encrypting said identification data of the communication terminal and said authentication data of said user, delivering the reference authentication data; a step of transmitting the reference authentication data to a processing server.
[8" id="c-fr-0008]
8. Processing method according to claim 6, characterized in that it comprises, when receiving data from said at least one input area by a processing server, at least one comparison step between at least one data transmitted within said input area and the reference authentication data, delivering a validation assertion of the transaction.
[9" id="c-fr-0009]
9. Intelligent communication terminal (TC) characterized in that it comprises a transactional data processing module (ModT) and a contactless data acquisition module (ModSC), characterized in that the processing module (ModT) ) comprises: detection means (100), a display of at least one input area (ZoS) relating to payment means data; activation means (110), the non-contact data reading module (ModSC); means (120) for obtaining, by the contactless data reading module (ModSC), at least one piece of payment means data from a payment means; means (130) for providing said at least one input area (ZoS) with at least one payment means data previously obtained.
[10" id="c-fr-0010]
10. Computer program product downloadable from a communication network and / or stored on a computer-readable medium and / or executable by a microprocessor, characterized in that it comprises program code instructions for the execution of a process securing method according to claims 1 to 8, when executed by a processor.
类似技术:
公开号 | 公开日 | 专利标题
EP3113099A1|2017-01-04|Payment container, creation method, processing method, devices and programs therefor
EP3221815B1|2021-05-19|Method for securing a payment token
FR3031613A1|2016-07-15|METHOD FOR PROCESSING A TRANSACTION FROM A COMMUNICATION TERMINAL
EP2873045A1|2015-05-20|Secure electronic entity for authorizing a transaction
WO2013021107A9|2013-05-23|Method, server and system for authentication of a person
EP3163487B1|2021-08-18|Method, terminal, and computer program for securing the processing of transactional data
EP3252692A1|2017-12-06|Method for supplying data relative to a payment transaction, device and corresponding program
EP3032799B1|2018-08-29|Method for authenticating a user, corresponding server, communication terminal and programs
EP2824625B1|2021-02-17|Method for conducting a transaction, corresponding terminal and computer program
EP2795947B1|2018-07-11|Method for pairing electronic equipments
FR3010215A1|2015-03-06|METHOD FOR PROCESSING TRANSACTIONAL DATA, DEVICES AND CORRESPONDING COMPUTER PROGRAMS.
EP3588418A1|2020-01-01|Method for conducting a transaction, terminal, server and corresponding computer program
EP3570238A1|2019-11-20|Method for conducting a transaction, terminal, server and corresponding computer program
FR3011111A1|2015-03-27|SECURING A TRANSMISSION OF IDENTIFICATION DATA
EP3857413A1|2021-08-04|Method for processing a transaction, device, system and corresponding program
WO2017077210A1|2017-05-11|Method for verifying identity during virtualization
FR3031217A1|2016-07-01|METHOD FOR VERIFYING A PAYMENT REQUEST INCLUDING DETERMINING THE LOCATION OF THE PROVISION OF A PAYMENT TOKEN
FR3031609A1|2016-07-15|METHOD OF PROCESSING A TRANSACTION FROM A COMMUNICATION TERMINAL
FR3031608A1|2016-07-15|METHOD FOR PROCESSING AUTHORIZATION TO IMPLEMENT A SERVICE, DEVICES AND CORRESPONDING COMPUTER PROGRAM
FR3008516A1|2015-01-16|TRANSACTION METHOD, TERMINAL AND CORRESPONDING COMPUTER PROGRAM.
GB2512613A|2014-10-08|Secure communications system
FR2976385A1|2012-12-14|Method for defining transaction to be carried out to purchase product in shop, involves obtaining transaction objective specification by server via one of three communications, where second communication includes reference to specification
FR2892875A1|2007-05-04|METHOD OF SECURING PAYMENTS BY CUTTING AMOUNTS
FR2963975A1|2012-02-24|ONLINE PAYMENT SYSTEM
同族专利:
公开号 | 公开日
FR3042894B1|2018-10-12|
ES2894899T3|2022-02-16|
CA2946570A1|2017-04-27|
EP3163487A1|2017-05-03|
US20170116609A1|2017-04-27|
EP3163487B1|2021-08-18|
引用文献:
公开号 | 申请日 | 公开日 | 申请人 | 专利标题
US20110225094A1|2010-03-09|2011-09-15|Ayman Hammad|System and method including dynamic verification value|
US20110270757A1|2010-04-09|2011-11-03|Ayman Hammad|System and method for securely validating transactions|
EP2256645A1|2009-05-29|2010-12-01|Incard SA|Method for producing at least a portion of a data visualization layout on a display of a device provided with at least a Smart Card, method for codifying a plurality of HTML instructions and corresponding system|
US20120221474A1|2011-02-24|2012-08-30|Skycore Llc|Secure Electronic Ticketing using Mobile Communication Devices over the Internet|
US8313036B1|2011-09-16|2012-11-20|Google Inc.|Secure application directory|
JP6414855B2|2013-11-06|2018-10-31|華為終端(東莞)有限公司|Page operation processing method and apparatus, and terminal|
US9780953B2|2014-07-23|2017-10-03|Visa International Service Association|Systems and methods for secure detokenization|
US20160026997A1|2014-07-25|2016-01-28|XPressTap, Inc.|Mobile Communication Device with Proximity Based Communication Circuitry|
US10333696B2|2015-01-12|2019-06-25|X-Prime, Inc.|Systems and methods for implementing an efficient, scalable homomorphic transformation of encrypted data with minimal data expansion and improved processing efficiency|KR102088451B1|2012-02-29|2020-03-12|모비웨이브 인코포레이티드|Method, device and secure element for conducting a secured financial transaction on a device|
TWI630816B|2017-02-07|2018-07-21|淡江大學|Visible light identification device, visible light identification system having the same and method thereof|
CN112508552A|2017-12-06|2021-03-16|创新先进技术有限公司|Writing-in and payment method and device of NFC portable device and NFC portable device|
法律状态:
2016-10-24| PLFP| Fee payment|Year of fee payment: 2 |
2017-04-28| PLSC| Publication of the preliminary search report|Effective date: 20170428 |
2017-10-30| PLFP| Fee payment|Year of fee payment: 3 |
2018-10-23| PLFP| Fee payment|Year of fee payment: 4 |
2019-10-23| PLFP| Fee payment|Year of fee payment: 5 |
2020-10-22| PLFP| Fee payment|Year of fee payment: 6 |
2021-10-22| PLFP| Fee payment|Year of fee payment: 7 |
2022-01-07| TP| Transmission of property|Owner name: BANKS AND ACQUIRERS INTERNATIONAL HOLDING, FR Effective date: 20211202 |
优先权:
申请号 | 申请日 | 专利标题
FR1560270|2015-10-27|
FR1560270A|FR3042894B1|2015-10-27|2015-10-27|METHOD FOR SECURING TRANSACTION DATA PROCESSING, TERMINAL AND CORRESPONDING COMPUTER PROGRAM|FR1560270A| FR3042894B1|2015-10-27|2015-10-27|METHOD FOR SECURING TRANSACTION DATA PROCESSING, TERMINAL AND CORRESPONDING COMPUTER PROGRAM|
EP16195082.9A| EP3163487B1|2015-10-27|2016-10-21|Method, terminal, and computer program for securing the processing of transactional data|
ES16195082T| ES2894899T3|2015-10-27|2016-10-21|Procedure for strengthening the security of transaction data processing, terminal and corresponding computer program|
CA2946570A| CA2946570A1|2015-10-27|2016-10-27|Process for safeguarding transactional data, corresponding computer terminal and software|
US15/335,868| US20170116609A1|2015-10-27|2016-10-27|Method for securing transactional data processing, corresponding terminal and computer program|
[返回顶部]